Virtual reality system

ABSTRACT

Operations carried out according to a method and operations carried out by a system including at least one processor and memory configured to store instructions include following operations. Those operations include: obtaining real world image data using one or more image data capturing devices positioned at a real world site; obtaining real world non-image data using one or more sensors positioned at the real world site; creating a scene model based on the obtained real world image data; integrating the obtained real world non-image data with the created scene model; carrying out an object recognition process to identify one or more objects included in the scene model; and rendering the scene model to create a VR scene in which one or more users are immersed using one or more VR playback devices.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 62/382,131, filed Aug. 31, 2016, which is incorporated herein byreference.

BACKGROUND

Virtual reality (VR) technology is becoming more prevalent in variousfields. Using a VR playing device, such as a head mount display (HMD),an audience member can be immersed in a VR scene that is created basedon a real world site and/or a group of artificially-created objects andhave an experience as if the audience member were physically in the VRscene. As the use of the VR technology expands into various fields, morevariety of functionalities within the VR scene will be in demand, sothat audience members can achieve intended purposes through the VRscene.

The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will become apparent to those of skill inthe art upon a reading of the specification and a study of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a diagram of an example of a synchronous scene buildingsystem.

FIG. 2 depicts a flowchart of an example of a method for synchronousscene building.

FIG. 3 depicts a diagram of an example of a synchronous scenecomposition system.

FIG. 4 depicts a flowchart of an example of a method for synchronousscene composition.

FIG. 5 depicts a diagram of an example of a VR experience system.

FIG. 6 depicts a flowchart of an example of a method for VR scenepresentation and interaction.

FIG. 7 depicts a diagram of an example of a scene filtering system.

FIG. 8 depicts a flowchart of an example of a method for carrying outfiltering of a VR scene.

DETAILED DESCRIPTION

FIG. 1 depicts a diagram 100 of an example of a synchronous scenebuilding system. The diagram 100 includes a computer-readable medium(CRM) 102, one or more sensors 104 coupled to the CRM 102, an elementdatastore 106 coupled to the CRM 102, a scene datastore 108 coupled tothe CRM 102, a synchronous scene composition system 110 coupled to theCRM 102, one or more on-scene element augmentation devices 112 coupledto the CRM 102, one or more VR playback devices 114 coupled to the CRM102, a scene filtering system 116 coupled to the CRM 102, and a scenedistribution system 118 coupled to the CRM 102.

The CRM 102 and other CRMs discussed in this paper are intended toinclude all mediums that are statutory (e.g., in the United States,under 35 U.S.C. 101), and to specifically exclude all mediums that arenon-statutory in nature to the extent that the exclusion is necessaryfor a claim that includes the CRM to be valid. Known statutory CRMsinclude hardware (e.g., registers, random access memory (RAM),non-volatile (NV) storage, to name a few), but may or may not be limitedto hardware.

The CRM 102 and other computer readable mediums discussed in this paperare intended to represent a variety of potentially applicabletechnologies. For example, the CRM 102 can be used to form a network orpart of a network. Where two components are co-located on a device, theCRM 102 can include a bus or other data conduit or plane. Depending uponimplementation-specific or other considerations, the CRM 102 can includewired communication interfaces and wireless communication interfaces forcommunicating over wired or wireless communication channels. Where afirst component is located on a first device and a second component islocated on a second (different) device, the CRM 102 can include awireless or wired back-end network or LAN. The CRM 102 can alsoencompass a relevant portion of a WAN or other network, if applicable.Enterprise networks can include geographically distributed LANs coupledacross WAN segments. For example, a distributed enterprise network caninclude multiple LANs (each LAN is sometimes referred to as a BasicService Set (BSS) in IEEE 802.11 parlance, though no explicitrequirement is suggested here) separated by WAN segments. An enterprisenetwork can also use VLAN tunneling (the connected LANs are sometimesreferred to as an Extended Service Set (ESS) in IEEE 802.11 parlance,though no explicit requirement is suggested here). Depending uponimplementation or other considerations, the CRM 102 can include aprivate cloud under the control of an enterprise or third party, or apublic cloud.

The devices, systems, and CRMs described in this paper can beimplemented as a computer system or parts of a computer system or aplurality of computer systems. In general, a computer system willinclude a processor, memory, non-volatile storage, and an interface. Atypical computer system will usually include at least a processor,memory, and a device (e.g., a bus) coupling the memory to the processor.The processor can be, for example, a general-purpose central processingunit (CPU), such as a microprocessor, or a special-purpose processor,such as a microcontroller.

The memory can include, by way of example but not limitation, randomaccess memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM).The memory can be local, remote, or distributed. The bus can also couplethe processor to non-volatile storage. The non-volatile storage is oftena magnetic floppy or hard disk, a magnetic-optical disk, an opticaldisk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, amagnetic or optical card, or another form of storage for large amountsof data. Some of this data is often written, by a direct memory accessprocess, into memory during execution of software on the computersystem. The non-volatile storage can be local, remote, or distributed.The non-volatile storage is optional because systems can be created withall applicable data available in memory.

Software is typically stored in the non-volatile storage. Indeed, forlarge programs, it may not even be possible to store the entire programin the memory. Nevertheless, it should be understood that for softwareto run, if necessary, it is moved to a computer-readable locationappropriate for processing, and for illustrative purposes, that locationis referred to as the memory in this paper. Even when software is movedto the memory for execution, the processor will typically make use ofhardware registers to store values associated with the software, andlocal cache that, ideally, serves to speed up execution. As used herein,a software program is assumed to be stored at an applicable known orconvenient location (from non-volatile storage to hardware registers)when the software program is referred to as “implemented in acomputer-readable storage medium.” A processor is considered to be“configured to execute a program” when at least one value associatedwith the program is stored in a register readable by the processor.

In one example of operation, a computer system can be controlled byoperating system software, which is a software program that includes afile management system, such as a disk operating system. One example ofoperating system software with associated file management systemsoftware is the family of operating systems known as Windows® fromMicrosoft Corporation of Redmond, Wash., and their associated filemanagement systems. Another example of operating system software withits associated file management system software is the Linux operatingsystem and its associated file management system. The file managementsystem is typically stored in the non-volatile storage and causes theprocessor to execute the various acts required by the operating systemto input and output data and to store data in the memory, includingstoring files on the non-volatile storage.

The bus can also couple the processor to the interface. The interfacecan include one or more input and/or output (I/O) devices. Dependingupon implementation-specific or other considerations, the I/O devicescan include, by way of example but not limitation, a keyboard, a mouseor other pointing device, disk drives, printers, a scanner, and otherI/O devices, including a display device. The display device can include,by way of example but not limitation, a cathode ray tube (CRT), liquidcrystal display (LCD), or some other applicable known or convenientdisplay device. The interface can include one or more of a modem ornetwork interface. It will be appreciated that a modem or networkinterface can be considered to be part of the computer system. Theinterface can include an analog modem, ISDN modem, cable modem, tokenring interface, satellite transmission interface (e.g. “direct PC”), orother interfaces for coupling a computer system to other computersystems. Interfaces enable computer systems and other devices to becoupled together in a network.

The computer systems can be compatible with or implemented as part of orthrough a cloud-based computing system. As used in this paper, acloud-based computing system is a system that provides virtualizedcomputing resources, software and/or information to end user devices.The computing resources, software and/or information can be virtualizedby maintaining centralized services and resources that the edge devicescan access over a communication interface, such as a network. “Cloud”may be a marketing term and for the purposes of this paper can includeany of the networks described herein. The cloud-based computing systemcan involve a subscription for services or use a utility pricing model.Users can access the protocols of the cloud-based computing systemthrough a web browser or other container application located on theirend user device.

A computer system can be implemented as an engine, as part of an engineor through multiple engines. As used in this paper, an engine includesone or more processors or a portion thereof. A portion of one or moreprocessors can include some portion of hardware less than all of thehardware comprising any given one or more processors, such as a subsetof registers, the portion of the processor dedicated to one or morethreads of a multi-threaded processor, a time slice during which theprocessor is wholly or partially dedicated to carrying out part of theengine's functionality, or the like. As such, a first engine and asecond engine can have one or more dedicated processors or a firstengine and a second engine can share one or more processors with oneanother or other engines. Depending upon implementation-specific orother considerations, an engine can be centralized or its functionalitydistributed. An engine can include hardware, firmware, or softwareembodied in a CRM for execution by the processor. The processortransforms data into new data using implemented data structures andmethods, such as is described with reference to the figures in thispaper.

The engines described in this paper, or the engines through which thesystems and devices described in this paper can be implemented, can becloud-based engines. As used in this paper, a cloud-based engine is anengine that can run applications and/or functionalities using acloud-based computing system. All or portions of the applications and/orfunctionalities can be distributed across multiple computing devices,and need not be restricted to only one computing device. In someembodiments, the cloud-based engines can execute functionalities and/ormodules that end users access through a web browser or containerapplication without having the functionalities and/or modules installedlocally on the end-users' computing devices.

As used in this paper, datastores are intended to include repositorieshaving any applicable organization of data, including tables,comma-separated values (CSV) files, traditional databases (e.g., SQL),or other applicable known or convenient organizational formats.Datastores can be implemented, for example, as software embodied in aphysical CRM on a specific-purpose machine, in firmware, in hardware, ina combination thereof, or in an applicable known or convenient device orsystem. Datastore-associated components, such as database interfaces,can be considered “part of” a datastore, part of some other systemcomponent, or a combination thereof, though the physical location andother characteristics of datastore-associated components is not criticalfor an understanding of the techniques described in this paper.

Datastores can include data structures. As used in this paper, a datastructure is associated with a particular way of storing and organizingdata in a computer so that it can be used efficiently within a givencontext. Data structures are generally based on the ability of acomputer to fetch and store data at any place in its memory, specifiedby an address, a bit string that can be itself stored in memory andmanipulated by the program. Thus, some data structures are based oncomputing the addresses of data items with arithmetic operations; whileother data structures are based on storing addresses of data itemswithin the structure itself. Many data structures use both principles,sometimes combined in non-trivial ways. The implementation of a datastructure usually entails writing a set of procedures that create andmanipulate instances of that structure. The datastores, described inthis paper, can be cloud-based datastores. A cloud-based datastore is adatastore that is compatible with cloud-based computing systems andengines.

Returning to the example of FIG. 1, the sensors 104 illustrated indiagram 100 are intended to represent devices having functions to obtainreal world parameters, such as visual data including images (2D stillimages, 2D video images, 3D still images, 3D video images, etc.), audiodata, osmic data, or haptic data. Examples of the sensors 104 are 3Dscanners, 2D and/or 3D cameras for still images (including 180 degreecameras and 360 degree cameras), 2D and/or 3D video cameras (including180 degree cameras and 360 degree cameras), microphones, temperaturesensors, speed meters, gyro sensors, accelerometers, GPS sensors,infrared imagers, smoke detectors, any detectors to detect chemicalmaterials, etc. to name several. In a specific implementation, thesensors 104 capture first data (e.g., audio data) and second data (e.g.,image data) to enable the creation of a scene with sensed datapositioned within a virtual space time in a manner that mimics thelocation of the sensed stimuli in the real world. The first data and thesecond data can be captured asynchronously (at different times) andsynchronized later by matching events, timestamps, or otherpoint-in-time occurrences in each individual input data set, or thefirst data and the second data could be captured at the same time,making the first and second data at least temporally synchronized.

In a specific implementation, the sensors 104 include wired or wirelessinterfaces through which the sensors 104 send obtained data over the CRM102. The function of wired or wireless communication may be implementedby a separate device from the sensors 104. In a specific implementation,the sensors 104 may include internal data storage in which the obtaineddata can be stored at least temporarily or for the purpose of backup.The internal data storage may support multiple file formats. In aspecific implementation, the sensors 104 may include an actuator tochange orientations of sensing portions (e.g., lens, microphones, etc.)of the sensors 104. For example, the actuator can include a motor torotate the sensing portions of the sensors 104. In a specificimplementation, the sensors 104 may include a locomotive mechanism tochange positions of the sensing portions of the sensors 104. Forexample, the locomotive mechanism includes one or more wheels to beplaced on the ground, a driving mechanism to rotate the wheels, and astand (e.g., tripods) to which a sensing portion of the sensors 104 isattached. In a specific implementation, each image data obtained by thesensors 104 is timestamped so as to be associated with real world time.The timestamp can be used as a hint to help synchronization andplacement of associated elements, but, in a specific implementation, thetimestamp is not the exclusive arbiter of time and may not evennecessarily be considered sufficient to an acceptable degree ofcertainty. For example, to treat timestamps as exclusive and sufficientarbiters, each sensor might need to be synchronized before capturingstimuli, but that is not possible in some implementations.

In a specific implementation, the sensors 104 are activated and/ordeactivated at different times. For example, some of the sensors 104 maybe active from prior to an agent arriving on-scene, such as securitycameras, and continue activation afterward, while others of the sensors104 might arrive with a particular actor, while yet others of thesensors 104 may be sporadic or random, such as pictures taken byunrelated bystanders or witnesses. For example, an operator of thesensors 104 may manually set up and activate one of the sensors 104 at areal world site, to start obtaining real world image data, and maymanually deactivate the one of the sensors 104 to cease obtaining thereal world image data with that sensor. In such a situation, forexample, an element (say, a getaway car) can be captured in securitycamera footage prior to arrival on the scene, a witness can record thegetaway car speeding away, a neighbor can state they heard a car takingoff at high speed at a particular time, an on-scene agent can takepictures of tire tracks, and an off-site agent can match the licenseplate of the getaway car to a known make and model (and owner). Each ofthese various elements can then be combined to define the getaway carelement (and perhaps augmented with a virtual car animation that matchesknown attributes derived from or corroborated with sensed data atspace-time locations that were not actually sensed).

In this paper, a scene (or VR scene) is intended to be a virtual volumeover a continuous or discontinuous period of time and VR objects in thevirtual volume. It should be noted a scene (or VR scene) may becharacterized as what amounts to a field of view (FOV) in contextsoutside of this paper, but in this paper, a scene is not a FOV and a FOVis explicitly referred to as such. Accordingly, as used in this paper, ascene (or VR scene) assumes unique (within the context of the scene)virtual space-time and VR objects within the virtual space-time.

In a specific implementation, the sensors 104 include unique identifiersthat can be used when transmitting data through a network. Uniqueidentifiers can include identifiers created in accordance with InternetProtocol version 4 (hereinafter referred to as “IPv4”), or identifierscreated in accordance with Internet Protocol version 6 (hereinafterreferred to as “IPv6”), of which both protocol versions are herebyincorporated by reference. Depending upon implementation-specific orother considerations, the sensors 104 can include applicablecommunication interfaces for receiving and sending data according to anapplicable wireless device protocol. Examples of applicable wirelessdevice protocols include Wi-Fi, ZigBee®, Bluetooth®, and otherapplicable low-power communication standards. Depending uponimplementation-specific or other considerations, the data transmissionis carried out with secured and encrypted connection from the sensors104.

In a specific implementation, the sensors 104 act as stations. Astation, as used in this paper, can be referred to as a device with amedia access control (MAC) address and a physical layer (PHY) interfaceto a wireless medium that complies with the IEEE 802.11 standard. Thus,for example, the network devices can be referred to as stations, ifapplicable. IEEE 802.11a-1999, IEEE 802.11b-1999, IEEE 802.11g-2003,IEEE 802.11-2007, and IEEE 802.11n TGn Draft 8.0 (2009) are incorporatedby reference. As used in this paper, a system that is 802.11standards-compatible or 802.11 standards-compliant complies with atleast some of one or more of the incorporated documents' requirementsand/or recommendations, or requirements and/or recommendations fromearlier drafts of the documents, and includes Wi-Fi systems. Wi-Fi is anon-technical description that is generally correlated with the IEEE802.11 standards, as well as Wi-Fi Protected Access (WPA) and WPA2security standards, and the Extensible Authentication Protocol (EAP)standard. In alternative embodiments, a station may comply with adifferent standard than Wi-Fi or IEEE 802.11, may be referred to assomething other than a “station,” and may have different interfaces to awireless or other medium.

In a specific implementation, the sensors 104 are configured to accessnetwork services in compliance with IEEE 802.3. IEEE 802.3 is a workinggroup and a collection of IEEE standards produced by the working groupdefining the physical layer and data link layer's MAC of wired Ethernet.This is generally a local area network technology with some wide areanetwork applications. Physical connections are typically made betweennodes and/or infrastructure devices (hubs, switches, routers) by varioustypes of copper or fiber cable. IEEE 802.3 is a technology that supportsthe IEEE 802.1 network architecture. As is well-known in the relevantart, IEEE 802.11 is a working group and collection of standards forimplementing wireless local area network (WLAN) computer communicationin the 2.4, 3.6 and 5 GHz frequency bands. The base version of thestandard IEEE 802.11-2007 has had subsequent amendments. These standardsprovide the basis for wireless network products using the Wi-Fi brand.IEEE 802.1 and 802.3 are incorporated by reference.

The element datastore 106 illustrated in diagram 100 is intended torepresent element data for the generating of a scene model. The elementdata includes data obtained by the sensors 104 and any available dataaccessible through a public or private network. Elements can includeboth objects and actions, and depending upon implementation-specificfactors, an element can include an object and action component, orelements can be of either an object or an action data structure type.Additional detail regarding the element datastore 106 is provided below.

The scene datastore 108 illustrated in diagram 100 is intended torepresent a store of generated scene models. In a specificimplementation, the scene datastore 108 is accessed by the VR playbackdevices 114 for real time streaming or playback on the devices.Additional detail regarding the scene datastore 108 is provided later.

The synchronous scene composition system 110 illustrated in diagram 100is intended to represent a system that augments elements in the elementdatastore 106 and composes a scene for storage in the scene datastore108. In a specific implementation, the scene composition system includesdevices with functions of managing (e.g., generating and editing) scenemodels, which are 3D frame representations of elements (objects andactions associated therewith) corresponding to objects at a real worldsite. Scenes can be built from any sensor data, however sparse, andaugmented over time as additional sensor data is received, analyzed,and/or augmented using other sources of data. In a specificimplementation, human and/or artificial agents augment elements inreal-time as a scene is played back synchronously with the augmentationthereof. A synchronous AR presentation is also possible in lieu of or inaddition to synchronous scene playback. A human agent making use of thesynchronous scene composition system 110 to augment elements or a sceneneed not be tied to a single device and can make use of differentdevices at different times (e.g., a desktop at home, a laptop at work, asmartphone on the train, different workstations, etc.). An asynchronousscene composition system (not shown) can be characterized as a separatesystem, and such a system has been implemented in prototype.Asynchronous scene composition can include techniques such as placingsensors within scenes enabling the determination of sensor point oforigin, integrate data from other sources recovered at later times, orother techniques described later. These techniques can even be appliedin systems that do not include synchronous scene composition.

The on-scene element augmentation devices 112 illustrated in diagram 100are intended to represent devices that are wearable or at leastportable, and that can be used at a real world location that correspondsto a virtual location within a scene, to augment elements associatedwith the scene. As used in this paper, “on-scene” is intended toindicate physical presence at a real world location that is beingcaptured for VR presentation. As used in this paper, “elementaugmentation” is intended to represent providing additional sensedperspectives and/or metadata (e.g., lab results, product brochures,annotations, etc.) applicable to an element that is to be augmented.Synchronous presentation, by definition, requires on-scene augmentationof elements for use in a scene, though the synchronous presentationcould conceivably be on-scene, such as when multiple on-scene elementaugmentation devices 112 work collaboratively. Thus, annotations made bya first agent in the (virtual) scene at a first location can beperceived at the same virtual location, or a corresponding real worldlocation via AR, by a second agent that is on-scene.

In a specific implementation, the on-scene element augmentation devices112 include wired or wireless interfaces through which the on-sceneelement augmentation devices 112 can send and receive data over the CRM102. Examples of the on-scene element augmentation devices 112 arelaptop computers, tablet computers, wireless devices (such as cellularphones, smartphones, or the like), or wearable devices (such as headmount displays, goggles, glasses, or the like), to name several. In aspecific implementation, on-scene element augmentation devices 112 willwork in coordination with at least some of the sensors 104. For example,a sensor of the sensors 104 can be incorporated into an on-scene elementaugmentation device of the on-screen element augmentation devices 112.

In a specific implementation, the on-scene element augmentation devices112 include unique identifiers which can be used in the transmission ofdata through a network. Depending upon implementation-specific or otherconsiderations, the data transmission is carried out with secured andencrypted connection by the on-scene element augmentation devices 112.In a specific implementation, the on-scene element augmentation devices112 act as stations. In a specific implementation, the on-scene elementaugmentation devices 112 are configured to access network services incompliance with IEEE 802.3.

The VR playback devices 114 illustrated in diagram 100 are intended torepresent devices capable of playing back a scene from the scenedatastore 108 in whatever state is currently available and authorized.In a specific implementation, the VR playback devices 114 include wiredor wireless interfaces through which the VR playback devices 114 cansend and receive data over the CRM 102. Examples of the VR playbackdevices 114 are desktop computers, laptop computers, tablet computers,wireless devices (such as cellular phones, smartphones, or the like),wearable devices (such as head mount displays, goggles, glasses, or thelike), cave automatic virtual environments (better known by therecursive acronym CAVE), or domes, to name several. The VR playbackdevices 114 can include a browser and a headset, but techniques fortransforming a smartphone into a 3D viewer are known (e.g., using GoogleCardboard), which enables a person to experience VR scenes with a singleassembled device. In a specific implementation, the VR playback devices114 may have a function of further displaying augmented reality (AR)objects or AR scenes overlaid on a physical scene perceivable by agentsin a real world. For example, a first of the VR playback devices 114 mayenable an agent or audience member to be immersed in a VR scene while asecond of the VR playback devices 114 may enable an agent to use AR toaugment a real world scene with elements, and the VR scene and AR scenemay be played concurrently such that the agent and audience member (oragent) can interact with each other. Thus, the on-scene elementaugmentation devices 112 can include VR playback devices 114.

In a specific implementation, scenes can be rendered for a display thatdoes not have a VR scene displaying function, such as a flat laptopscreen, which may be useful for debugging, including audience memberswho lack optimal tools in a presentation, or other purposes; the fullimpact of the VR experience currently requires some type of head (and/oreye) tracking mechanism, though neural interfaces could conceivablyreplace physical head (and/or eye) movement tracking. A multimediaexperience entails the use of both video and audio, so the VR playbackdevices 114 may also be equipped with headphones, earbuds, speakers, orother device for providing audio to a VR scene audience member. In aspecific implementation, at least one of the VR playback devices 114 hasan application installed for enabling a VR mode.

In a specific implementation, the VR playback devices 114 include uniqueidentifiers which can be used in the transmission of data through anetwork. Depending upon implementation-specific or other considerations,the data transmission is carried out with secured and encryptedconnection by the VR playback devices 114. In a specific implementation,the VR playback devices 114 act as stations. In a specificimplementation, the VR playback devices 114 are configured to accessnetwork services in compliance with IEEE 802.3.

The scene filtering system 116 illustrated in diagram 100 is intended torepresent a platform that facilitates management of scenes to limitinformation to that which is desired or allowed for audience members.Filters can limit information to a particular subset of information(e.g., undisputed information, information a jury is not entitled tosee, or information that is associated with a particular actor within ascene, to name a few).

The scene distribution system 118 illustrated in diagram 100 is intendedto represent a platform that facilitates the distribution of scenes fromthe scene datastore 108 for playback. Scenes can be, e.g., streamed froma server, downloaded to playback devices, or distributed in some otherapplicable manner. The scenes can be pre-filtered prior to distributionto devices without full authorization or display capabilities, or thefilters can be implemented at the devices (and may or may not beconfigurable).

In an example of operation, a system such as is illustrated in FIG. 1operates as follows. The sensors 104 provide real world data to theelement datastore 106. One or more human or artificial agents use thesynchronous scene composition system 110 to place elements from theelement datastore 106 within a scene model for storage in the scenedatastore 108. Creation of a scene model can entail integrating andsynchronizing data obtained from the sensors 104, obtainingsupplementary data from the sensors 104, integrating metadata fromsources other than the sensors 104, and augmenting elements in theelement datastore 106 with supplementary data or metadata. The on-sceneelement augmentation devices 112 provide real-time data to human agentsat a real world location associated with at least a portion of a scene.On-scene agents (including sensors 104 or agents using on-scene elementaugmentation devices 112) can be instructed or requested to providesupplementary data to an off-site location (e.g., dispatch) or tocollaborate with one another, and the supplementary data can be used toaugment elements in the element datastore 106. The VR playback devices114 enable playback of a scene in whatever state of development thescene is in. The VR playback devices 114 can be on-scene (synchronous),enabling, e.g., comparison of VR with real world; off-site(synchronous), facilitating, e.g., providing real-time updates for orrequests from human agents who are on-scene; and off-site(asynchronous), enabling, e.g., playback of a completed scenepresentation. Additional tools, not shown in diagram 100, can includetools that enable a human to more readily manage scene models, createnew elements (making components of a VR playback device act ascomponents of the synchronous scene composition system 110 or anasynchronous scene composition system); for example, an audience membercould annotate a scene, creating a new element and which, depending uponimplementation- and/or configuration-specific factors, may beincorporated into the scene. The scene filtering system 116 enablesplayback of requested or authorized portions of a scene at the VRplayback devices 114, by streaming the filtered scene to relevant onesof the VR playback devices 114, editing a scene with appropriate filtersfor provisioning to relevant ones of the VR playback devices 114 via thescene distribution system 118. The scene distribution system 118 canenforce filtering rules via an authorization system.

FIG. 2 depicts a flowchart 200 of an example of a method for synchronousscene building. This flowchart and other flowcharts described in thispaper illustrate modules (and potentially decision points) organized ina fashion that is conducive to understanding. It should be recognized,however, that the modules can be reorganized for parallel execution,reordered, modified (changed, removed, or augmented), wherecircumstances permit.

In the example of FIG. 2, the flowchart 200 starts at module 202, withobtaining real world data. Real world data can be captured with sensorsat real world locations (e.g., 3D data captured by sensors).

In the example of FIG. 2, the flowchart 200 continues to module 204 withstoring the real world data in an element datastore. In a specificimplementation, data obtained by sensors is stored as an element in theelement datastore. Alternatively, sensor data can also be treated as aseparate datastore and only included as a component of an element datastructure when the sensor data can be correlated with a real worldobject (or component of an object) and stored as part of the elementthat is correlated with the real world object. Other data can also bestored in what is at least conceptually a separate datastore from theelement datastore and included as a component of an element datastructure when the elements are augmented to include metadata.

In the example of FIG. 2, the flowchart 200 continues to module 206 withcreating a scene model using the element datastore. In a specificimplementation, a scene model is a 3D frame representation of one ormore real world sites with virtual objects correlated with real worldobjects at corresponding locations of the scene. Advantageously, thevirtual objects are elements that include metadata that can also beaccessed by an AR or VR audience member. The scene model can becharacterized as a framework for organizing elements in space and time.Elements can include objects corresponding to a real-world objects orcreatures (and actions and metadata associated therewith); for examplean element can be a car captured in a traffic camera image. Elements canalso include synthetic objects, such as objects created fordemonstrative purposes, that have no corresponding real-world object;for example, an arrow could be used to draw audience member attention toa car captured in a traffic camera image. Elements can include partiallysynthetic objects; for example, a traffic camera image may only show thefront of a car and the unsensed back of the car can be generatedsynthetically and used to create a full 3D model of the car. (Dependingupon implementation- and/or configuration-specific factors, filters canbe used to filter out the synthetic portion.) It may be noted a fullframework is sometimes unnecessary for AR presentation, making thismodule optional in some implementations.

In the example of FIG. 2, the flowchart 200 continues to module 208 withproviding a synchronous scene presentation to an on-scene agent. In aspecific implementation, element metadata can be provided to an on-sceneagent and presented in an augmented reality (AR) environment at the realworld location. Alternatively, a scene can be provided to an on-sceneagent as a VR presentation at the real-world location of the on-sceneagent, which may be desirable to facilitate comparisons between what iscaptured in the VR scene and what is extant at the real world scene.

In the example of FIG. 2, the flowchart 200 continues to module 210 withreceiving element augmentation data from an on-scene elementaugmentation device. An on-scene agent can collect supplemental dataabout real world objects stored as elements in the element datastore,aided by a synchronous AR or VR presentation, responsive to instructionsor advice from an off-site agent, pursuant to relevant protocols, or inaccordance with the on-scene agent's preferences. Advantageously, anon-scene agent is ideally situated to compare a scene (or elementsassociated therewith) to a real-world location during synchronouspresentation. In this paper, the collaboration between on-scene agentsand off-site agents where elements or scenes are presented, in whole orin part, to both the on-scene and off-site agents is referred to assynchronous presentation.

In the example of FIG. 2, the flowchart 200 ends at module 212 withfiltering a scene for asynchronous presentation at a VR device. In aspecific implementation, an audience member uses a VR playback device tobe immersed in a scene presented in VR, navigate the VR scene,manipulate VR objects in the VR scene, and control (manage) the VRscene. The scene can be filtered as appropriate for a given situation.For example, a jury may be prohibited from observing certain objects oractions pursuant to a judge's ruling. In another example, an audiencemember may request elements to be displayed that were extant at aparticular time (e.g., “show me the furniture as it was arranged at 3P.M.”).

FIG. 3 depicts a diagram 300 of an example of a synchronous scenecomposition system. The diagram 300 includes an element datastore 302, ascene datastore 304, and a synchronous scene composition system 305coupled to the element datastore 302 and the scene datastore 304. Thesynchronous scene composition system 305 includes a scene model creationengine 306, a media integration subsystem 308, which includes an imageintegration engine 310, an audio integration engine 312, and anadditional data integration engine 314, an object recognition subsystem316, which includes an object segmentation engine 318, an objectsearching engine 320, an object matching engine 322, and an objectlibrary 324, and an active learning engine 326, and an event recognitionengine 328.

In the example of FIG. 3, the element datastore 302 is intended torepresent element data structures used in the creation of scene modelsor for AR. In an implementation, element data are generated from sensordata and augmented with supplementary sensor data or with data fromother sources. In a specific implementation, synthetic elements can becreated by agents and/or audience members.

In the example of FIG. 3, the scene datastore 304 is intended torepresent scene data structures that act as a framework onto whichelement data structures can be located in space and time.

In the example of FIG. 3, the scene model creation engine 306 isintended to represent specifically-purposed hardware and software thatcreates a scene model using real world image data obtained from one ormore sensors. In a specific implementation, when a point cloud model ora mesh model representing a part or the entire real world scene areobtained from a sensor (e.g., 3D scanner), the scene model creationengine 306 places data of the point cloud model or mesh model in a VRenvironment so as to match the scale of the VR environment. In aspecific implementation the scene model creation engine 306 can derive apoint cloud model from a mesh model (e.g., when the point cloud model isnot obtained from a sensor that generates point cloud data, such as a 3Dscanner). Alternatively or in addition, the scene model creation enginecan derive a mesh model from a point cloud model. In a specificimplementation, the scene model creation engine 306 can derive a pointcloud or mesh model from raw data if the point cloud or mesh model isnot provided from the sensors. For example, when one more 2D or 3D imagedata are obtained from one or more sensors (e.g., 2D and/or 3D cameras),the scene model creation engine 306 can apply photogrammetry on theobtained image data and generate frame image data. In a specificimplementation, the scene model creation engine 306 uses external inputssuch as GPS mapping data that are obtained from GPS sensors and widegeographic mapping data that are publicly available (e.g., Google Maps),and manual agent inputs, to associate the scene model to a geographiclocation. More particularly, the scene model creation engine 306associates the entire scene model with a master geographic area, whichmay or may not be a continuous area, and each object within the scenemodel with geographic coordinates. It may be noted the “area” canrepresent a space-time volume and coordinates can represent a locationin space-time.

In the example of FIG. 3, the media integration subsystem 308 isintended to represent specifically-purposed hardware and software thatintegrates real world data obtained from one or more sensors into ascene model created by the scene model creation engine 306. For example,the image integration engine 310 of the media integration subsystem 308can integrate real world image data obtained from one or more sensorsinto a scene model at space-time coordinates corresponding to real-worldcoordinates for a real-world object captured in the image, or near suchcoordinates. In a specific implementation, when a 2D/3D image (e.g.,picture and video) is obtained from a sensor (e.g., a still camera and avideo camera), the image integration engine 310 calculates a relativepoint of capture (POC), i.e., a position and orientation at which the2D/3D image was captured, and a field of view (FOV), i.e., a size of the2D/3D imaging range in the real world that was captured. Depending uponimplementation- and/or configuration-specific parameters, the 2D/3Dimage can include 180 degree images or 360 degree images captured usingspecialized lenses to obtain 180 degree images and 360 degree images. Ina specific implementation, the image integration engine 310 places the2D/3D images obtained by the sensors in association with the calculatedPOC in the scene model at virtual space-time coordinates correspondingto space and time in the real world.

The audio integration engine 312 of the media integration subsystem 308integrates real world audio data obtained from one or more sensors intoto the scene model. For example, the audio integration engine 312 canoperate to obtain a point of capture (POC) from a position of sensors(e.g., microphones) at a time of recording. The position of sensors maybe obtained: i) from a position of known devices (e.g., cameras) whenthe sensors are attached thereto; ii) from a position of a 3D sensorwhen the audio data is recorded at the 3D sensor; iii) from an estimatedposition, or iv) from agent inputs. In a specific implementation, whenaudio data is obtained from a sensor (e.g., microphone), the audiointegration engine 312 integrates the audio data into a master audiotrack prepared for the scene model. For example, when each time a newaudio track (data) is obtained, the audio integration engine 312 placesthe audio track at a virtual space-time location within the master audiotrack that is (ideally) correlated with the real-world source of theaudio (and/or the location of the sensor capturing the audio data). In aspecific implementation, the audio integration engine 312 places arepresentation (e.g. icon) representing the audio data obtained by thesensors in association with the calculated POC in the scene model,integrated with the virtual space-time of the scene model. In a specificimplementation, the audio integration engine 312 associates each audiotrack with geographic coordinates corresponding to the calculated POCwhen the geographic coordinates are obtained and with a mastergeographic area when the geographic coordinates are not obtained. In thealternative, the audio integration engine 312 may estimate a source fromwhich a sound corresponding to at least a portion of the audio data isgenerated, and associate the portion of the audio data with theestimated source. Audio tracks may later be augmented by separatingfirst audio from second audio within a track and associating the firstand second audio with first and second elements.

In the example of FIG. 3, the additional data integration engine 314 ofthe media integration subsystem 308 integrates real world data otherthan image and audio data into the scene model created by the scenemodel creation engine 306. In a specific implementation, the other realworld data may include temperature data, precipitation data, humiditydata, telemetry data, wind data, speed data, acceleration data, smelldata, vibration data, etc. In a specific implementation, the additionaldata integration engine 314 operates to obtain the point of capture(POC) from position of sensors (e.g., microphones) at the time ofsensing, and associates the obtained data with the POC or the mastergeographic location of the scene model. In a specific implementation,the other real world data may be obtained at the time when image datafor creating the scene model are captured by a sensor, or later in timeafter the image data for creating the scene model are captured by asensor. In a more particular example, a DNA test result obtained laterbased on analysis of a real-world object can be introduced into thescene model as metadata of an element corresponding to the real-worldobject.

In the example of FIG. 3, the object recognition subsystem 316 isintended to represent specifically-purposed hardware and software thatcarries out object recognition with respect to objects included in ascene model. In a specific implementation, the object segmentationengine 318 of the object recognition subsystem 316 detects objects inthe scene model and segments the detected objects into individualobjects. In a specific implementation, the object searching engine 320of the object recognition subsystem 316 searches for one or morecandidate model objects corresponding to each of the segmented objectsfrom the object library 324, where model object data is stored. In aspecific implementation, the object matching engine 322 matches data ofeach of the segmented objects (e.g., point cloud data or mesh data) withdata of the corresponding candidate model objects (e.g., point clouddata or mesh data) obtained from the object library 324 and recognizes acandidate model object that is a closest match to features of thesegmented object. An element corresponding to the segmented object canbe provided with metadata for the closest match or probabilities for aset of possible matches. In a specific implementation, the activelearning engine 326 of the object recognition subsystem 316 accumulatescalculation results obtained from the object segmentation engine 318,the object searching engine 320, and the object matching engine 322, anduses the accumulated calculation results for higher calculation accuracyby each of the object segmentation engine 318, the object searchingengine 320, and the object matching engine 322. In a specificimplementation, the active learning engine 326 further solicits agentinputs regarding the object recognition process and accuracy thereof.

In a specific implementation, the object recognition subsystem 316enables completion of object portions that are not visible in image dataobtained from sensors (e.g., object portions that opposite to objectportions facing POC, object portions that are outside FOV). When avisible portion of the object does not provide sufficient data tosupplement the non-visible portion of the object with adequatereliability (threshold for adequate reliability will depend uponimplementation- and/or configuration-specific factors and may be set toinfinity, or some other unattainable threshold value, if constructivecertainty is never adequate), the object recognition subsystem 316 mayconfigure the non-visible portion as a grayed-out portion. In a specificimplementation, the object recognition subsystem 316 switchesconfiguration of a non-visible portion of an object between asupplemented portion and a grayed-out portion depending on a usersetting. This functionality of switching between the supplementedportion and the grayed-out portion may help an audience member to switcha scene model based on whether or not supplementing of the non-visibleportion of an object is scientifically reliable and admissible asevidence in terms of an evidence rule (e.g. Daubert rule). At leastconceptually, the switch can be accomplished using a filter to exclude(filter out), highlight (gray out), or present (do not filter)constructive recreation.

In a specific implementation, the object recognition subsystem 316carries out object ontology with respect to each recognized object toclassify the object by hierarchical levels. In an example, when arecognized object is Colt M1911 pistol, the recognized object isclassified as firearms in a first hierarchical level, as a pistol in asecond hierarchical level, as a product of Colt's Manufacturing Companyin a third hierarchical level (e.g., manufacturer level). In addition,any other relevant attribute information (e.g., manufactured year,caliber size, etc.) can be used for the hierarchical levels. In anotherexample, when a recognized object is a fossil of a brachiosaurus, therecognized object is classified as a fossil in a first hierarchicallevel, as a dinosaur in a second hierarchical level, as JurassicMorrison Formation in a third hierarchical level, and other features(e.g., era, dating, etc.) can be used for the hierarchical levels. In aspecific implementation, the object recognition subsystem 316 enables,based on the classification of recognized objects, a audience member tosearch an object in a scene model using the hierarchical levels or thename of the object as a key. In a specific implementation, a virtualuser interface (UI) to input a search key may be presented in the sceneby the object recognition subsystem 316.

In a specific implementation, the object recognition subsystem 316, moreparticularly the object matching engine 322 thereof, compares an objectthat has been recognized and classified through the object recognitionprocess and a hypothetical object having features described by agentinputs, and detects matching features and non-matching features betweenthe recognized object and the hypothetical object. In an examplesituation, this functionality provides a way to determine witnesstestimony accuracy.

In a specific implementation, the event recognition engine 328 carriesout ontological event categorization with respect to each recognizedobject to classify the event of the recognized object by each ofhierarchical levels, in a manner similar to the object classificationcarried out by the object recognition subsystem 316. The eventrecognized by the event recognition engine 328 may be any action inassociation with a recognized object, such as moving, swinging,rotating, lighting, flashing, making noises, melting, evaporating,solidifying, decaying, changing color, and so on. In addition, any otherrelevant attribute information (e.g., a time line when the eventoccurred, and etc.) can be used for the hierarchical levels. Objectscapable of self-movement (including human actors) and/or objects withdiffering mechanical properties can have different movement ontologies.

In a specific implementation, the event recognition engine 328 tracksmovement in association with objects in a scene model. For example, whena person is moving around a real world site, where multiple sensors areset to capture image data of the real world site, entry to and exit fromeach FOV of sensors can be tracked and timestamped.

In a specific implementation, the event recognition engine 328 carriesout comparison between an event of an object that has been recognizedand classified through the event recognition process and a hypotheticalevent of the object described by agent inputs, and detects matchingfeatures and non-matching features between the recognized event and thehypothetical event. In an example situation, this functionality providesa way to determine witness testimony accuracy.

In an example of operation, a system such as is illustrated in FIG. 3operates as follows. The scene model creation engine 306 creates a scenemodel based on real world image data obtained from sensors, which arestored as elements in the element datastore 302. The media integrationsubsystem 308 integrates and synchronizes media data of the elementsinto the scene model stored in the scene datastore 304. Specifically,the image integration engine 310 integrates and/or synchronizes realworld image data of the elements stored in the element datastore 302into the scene model, the audio integration engine 312 integrates and/orsynchronizes real world audio data of the elements into the scene model,and the additional data integration engine 314 integrates and/orsynchronizes other real world data of the elements into the scene model.

Continuing the example of operation, the object recognition subsystem316 recognizes objects included in the scene model to better conformelements (and sub-elements) to specific real-world objects (and objectcomponents). Specifically, the object segmentation engine 318 detectsobjects in the scene model and segments the detected objects intoindividual objects, the object searching engine 320 searches for one ormore candidate model objects corresponding to each of the segmentedobjects from the object library 324, the object matching engine 322compares parameters of the segmented objects with parameters of thecorresponding candidate model objects obtained from the object library324 to obtain a match probability or probabilities, and the activelearning engine 326 accumulates calculation results and uses theaccumulated calculation results for higher calculation accuracy. Theevent recognition engine 328 recognizes events of the recognized objectsincluded in the scene model, and the elements and scene models areupdated accordingly.

FIG. 4 depicts a flowchart 400 of an example of a method for synchronousscene composition. The flowchart 400 starts at module 402 with creatinga scene model. In a specific implementation, the scene model is createdfrom objects identified from real world stimuli detected by sensors. Forexample, the real world stimuli can be electromagnetic radiationobtained by a 3D scanner that generates point cloud data or by one ormore 2D or 3D cameras and stitched together using photogrammetrytechniques to generate mesh data, and objects can be identified from thepoint cloud data or mesh data. Instead or in addition, the scene modelcan be created using synthetic elements, such as objects used to directaudience member attention, but that are not actually correlated with anyreal world stimuli. A scene model can, at least conceptually, also be arelatively sparse virtual space-time due to a lack of sensor data. Forexample, a case file could be opened for a crime scene investigationthat involves identifying a scene prior to obtaining any on-scene data,and the scene can be developed over time as additional data is received.In such an example, the scene model can be thought of as a frame onwhich elements can be positioned.

In the example of FIG. 4, the flowchart 400 continues to module 404 withintegrating on-scene data into the scene model. The on-scene data caninclude media data, such as image data obtained through 2D/3D images,audio data obtained through microphones, or other data obtained fromon-scene sensors. Media data can also be added asynchronously at a latertime, such as by an investigator who adds a voice memo after leaving thescene or a forensics investigator who takes a supplemental photo of amurder weapon. Media data can also be taken from data sources that arenot directly drawn from elements or actors, such as an image of afirearm that is alleged to have been used (though no image of thealleged murder weapon is available), taken from an object library. Inthe latter case, the object will typically have been recognized, asdescribed in the next module. The on-scene data can also includenon-media data, such as a memo created by an on-scene agent. It may benoted that most non-media data can be represented in graphical form (asmedia), but the non-media data itself has no identifiable real-worldphysical structure (though it can typically act as metadata for anelement that is correlated to a real world object with a physicalstructure).

In the example of FIG. 4, the flowchart 400 continues to module 406 withrecognizing objects included in the scene model. In a specificimplementation, detected objects are matched with reference objects anda best matching reference object may be recognized (identified) as thedetected object. Elements associated with detected objects can includeprobabilities associated with reference objects indicative of thelikelihood the detected object is or shares characteristics with one ormore reference objects. Human or artificial agents may be sufficientlycapable or confident to recognized and identify objects. In a specificimplementation, recognized objects are classified in one or morehierarchical levels, so that object searching based on the hierarchicallevels can be carried out. The classification can occur based uponidentifying an object at at least one hierarchical level. For example,categorizing an object as “an assault rifle” is a higher hierarchicallevel than as a “AK-47.”

In the example of FIG. 4, the flowchart 400 continues to module 408 withrecognizing events associated with recognized objects included in thescene model. Associations with an object can include the object takingan action (the event), the object being subjected to an action (theevent), or the object being in some degree of proximity to an action(the event). Events can be limited by sensor capabilities. For example,an object that disappears may disappear because a sensor is no longercapable of detecting it, even if the object did not move. In a specificimplementation, an event (action) associated with one or more recognizedobjects is recognized and the recognized event is classified in one ormore hierarchical levels, so that an event search based on thehierarchical levels can be carried out. The classification can occurbased upon identifying an event at at least one hierarchical level. Forexample, categorizing an object as “having been moved” (potentially dueto an early image showing the object and a later image not showing theobject) is at a higher hierarchical level than as “picked up and carriedaway by an actor.” (The latter may be characterized as multiple events.)

In the example of FIG. 4, the flowchart 400 ends at module 410 withstoring the scene model for distribution. In a specific implementation,the scale of the scene model is set to a scale corresponding to a realworld geography and time period(s), both of which can be eithercontinuous or discrete. A master scene model, with all elements andareas over the entire time period(s), may or may not be made availablefor distribution. For example, a scene model stored for distribution mayfilter out elements, geographies, or times audience members are notauthorized to perceive. Alternatively, a scene model elements areassociated with user credentials, so that audience members withappropriate user credentials have selective access to a master scenemodel.

FIG. 5 depicts a diagram 500 of an example of an on-scene elementaugmentation system. The diagram 500 includes an element augmentationsystem 502, sensors 504 coupled to the element augmentation system 502,an element datastore 506 coupled to the element augmentation system 502,and a scene datastore 508 coupled to the element augmentation system502. The element augmentation system 502 includes a synchronouscommunication engine 510, a sensor control engine 512, an AR engine 514,a VR scene rendering subsystem 516, which includes a VR scene navigationengine 518, a multiuser navigation engine 520, a VR scene guiding engine522, and a VR scene observing engine 524, an object manipulation engine526.

In the example of FIG. 5, the element augmentation system 502 isintended to represent specifically-purposed hardware and software usedfor synchronous scene composition. Synchronous scene compositioninvolves synchronous communication between agents to build a virtualscene corresponding to a real world scene at which at least one of theagents is located. The elements of the virtual scene are augmented inreal-time and element data associated with the scene is available to theagents as the virtual scene is augmented. The sensors 504, elementdatastore 506, and scene datastore 508 can be implemented as describedwith reference to the sensors 104 (FIG. 1), the element datastore 106(FIG. 1), and the scene datastore 108 (FIG. 1).

The synchronous communication engine 510 is intended to represent acommunication path interface for a first agent. The first agent is anon-scene agent that uses the synchronous communication engine 510 toaccess at least a portion of an element from the element datastore 506(accessed element data). The first agent may or may not access the scenedatastore 508, depending upon implementation- and/orconfiguration-specific factors. The first agent provides data that isused to generate one or more new elements for storage in the elementdatastore 506 (element creation data and/or instructions) or to augmentexisting elements in the element datastore 506 (element update dataand/or instructions). Although it is generally desirable to keep arecord of all activity in at least some implementations, such as crimescene investigation implementations, the first agent may also providedata that is used to delete elements from the element datastore 506(element deletion data and/or instructions). Thus, with limitations thatare implementation- and/or configuration-specific, the first agent canhave create, read, update, and delete (CRUD) access to the elementdatastore 506 via the synchronous communication engine 510 and may ormay not have CRUD access to the scene datastore 508.

A second agent can communicate with the first agent while the firstagent is on-scene. The second agent can also have CRUD access to theelement datastore 506 or scene datastore 508 while the first agent ison-scene, giving the first agent access to updated element data whileon-scene. The second agent can also provide instructions or requests tothe first agent such that the first agent can act on the instructions orrequests while on-scene. For example, the second agent could request thefirst agent gather an organic sample or take a picture. The instructionsor requests can be associated with spatial coordinates the first agentcan act upon using AR or verbal queues. For example, the first agent canbe instructed to take a picture of an object in the north-east corner ofthe dining room or to take a picture of an object identified with anarrow (in AR).

It is assumed for illustrative purposes the first and second agents areauthorized to access all elements, including metadata, as well as otherresources, without restriction. However, just as a VR presentation canbe filtered (see, e.g., the scene filtering system 116 of FIG. 1),depending upon implementation- and/or configuration-specific factors,agents can be limited by access rights.

The sensor control engine 512 is intended to represent a commandinterface and associated hardware and (if applicable) software for thefirst agent to control one or more of the sensors 504. The commandinterface includes, for example, a camera application on a smartphonethat is used to command the smartphone to take a picture, an activationswitch of a 3D scanner, or a wireless activation switch for a sensor.The second agent may or may not also have access to the sensor controlengine 512.

The AR engine 514 is intended to represent hardware and typicallysoftware that is used to display at least a portion of the elementdatastore 506 to the first agent in correlation with the real worldscene. Advantageously, as the element datastore 506 is updated by thefirst agent or the second agent, the AR engine 514 provides AR using theupdated data to the first agent while the first agent is still on-scene.The second agent may or may not also have access to the AR engine 514.

The VR scene rendering subsystem 516 is intended to represent hardwareand software used to render a scene from the scene datastore 508 to VRplayback devices. The VR scene rendering subsystem 516 can be consideredoptional in synchronous mode because the first agent, who is on-scene,may have no need for VR presentation (favoring AR that augments the realworld scene) and the second agent may also be on-scene and may have noneed for VR for similar reasons. However, if the second agent isoff-site, it may be desirable to provide the second agent with VRcapabilities. Moreover, the VR scene rendering subsystem 516 is assumedto be essential in asynchronous mode for at least some implementations,such as when the scene is built for the purpose of assisting off-siteaudience members to experience a crime scene that is no longer extant inthe real world.

The VR scene navigation engine 518 of the VR scene rendering subsystem516 enables audience members to navigate through a VR scene. In aspecific implementation, the VR scene navigation engine 518 causes everymovement and step taken by an audience member in a real world to berepresented in a similar same scale movement within the VR scene(hereinafter referred to as step-by-step walking). It may be noted thatstep-by-step walking is often confined within a safe area and navigationcontrols must be used to move a scene around to enable continuouswalking. In a specific implementation, the VR scene navigation engine518 enables an audience member to review or play media (e.g., pictures,video, relevant environmental data, etc.) placed in the VR scene(hereinafter referred to as media review), for example, by selecting anicon at a location in the VR scene associated with the media.

In a specific implementation, the VR scene navigation engine 518 enablesan audience member to “teleport” to a desired point in the VR scene(without the audience member physically walking to a corresponding pointin a real world). For example, upon an audience member selecting adestination point in the VR scene, a position of the audience member inthe VR scene is instantly moved to the destination point and a new FOVis presented to the audience member's VR playing device. In a specificimplementation, the VR scene navigation engine 518 enables an audiencemember to “teleport” to a destination position, by providing theaudience member a scaled-down VR scene (dollhouse VR scene) within thenormal-scale VR scene and allowing the audience member to move theaudience member's avatar within the scaled-down VR scene to acorresponding destination position within the scaled-down VR scene. Forexample, upon an audience member operation to invoke a dollhouseteleportation, the VR scene navigation engine 518 enables an audiencemember to grab the audience member's avatar in a dollhouse VR scene andmove the audience member's avatar to a desired location within thedollhouse VR scene. After a destination position of the audiencemember's avatar is settled, the a position of the audience member in thenormal-scale VR scene is instantly moved to a point corresponding to thedestination position in the dollhouse VR scene and a new FOV ispresented to the audience member's VR playing device.

In a specific implementation, the VR scene navigation engine 518 enablesan audience member to gradually move in a pointed direction in the VRscene (without the audience member physically walking to a correspondingpoint in a real world), and this move is referred to as “directed move”hereinafter. For example, upon an audience member pointing a directionin the VR scene and indicating a moving speed in the VR scene, aposition of the audience member is moved in the pointed direction at theindicated speed, and gradually shifting FOVs are presented to theaudience member's VR playing device. In a specific implementation, theVR scene navigation engine 518 enables an audience member to control theVR scene with verbal commands and/or gestures. For example, upon anaudience member verbally commanding to show all metal objects withemphasis (e.g. highlight), the VR scene navigation engine 518 causesobjects that are characterized as metal objects to be displayed in theVR scene with emphasis. For example, upon an audience member verballycommanding to face toward south, the VR scene navigation engine 518causes the FOV of the audience member to be changed to a new FOV facingsouth. For example, upon an audience member making a hand gesture tovolume up audio of the VR scene, the VR scene navigation engine 518causes audio of the VR scene to be increased. For example, upon anaudience member verbally calling up a particular identifier of media(e.g., picture, video, dictionary), the VR scene navigation engine 518causes the called-up media to be displayed in the VR scene. Thoseexample of audience member interaction with the VR scene and otheraudience member interaction with the VR scene described in this paperare not limited to particular interfaces, and any interfaces, includingbut not limited to, keyboard, a handheld controller, a hand signalsensor, a gesture sensor, a voice recognition system, a gaze anglesensor, and so on, can be employed.

The multiuser navigation engine 520 of the VR scene rendering subsystem516 enables multiple audience members to be immersed in the same VRscene concurrently. In a specific implementation, the multiusernavigation engine 520 supports functions supported by the VR scenenavigation engine for audience members in the VR scene, such as,step-by-step walking, media review, teleportation, dollhouseteleportation, directed move, and verbal/gesture command. That is, anaudience member in the VR scene is capable of operating those functionsindependently from other audience members.

In a specific implementation, the multiuser navigation engine 520further enables multiple audience members to interact with each other inthe VR scene. One particular way of multiuser interaction is verbalcommunication. In a specific implementation, an audience member who isimmersed in a VR scene using a VR playback device can have his or hervoice to be delivered to a target audience member immersed in the VRscene by a voice message, by selecting the target audience memberphysically or virtually. The voice can be captured by the VR playbackdevice (e.g., microphone attached to or embedded in the VR playbackdevice) that the originating audience member uses, and reproduced by aVR playing device that the target audience member uses.

Another particular way of interaction is visual communication. In aspecific implementation, an audience member who is immersed in a VRscene using a VR playback device can have a text message to be deliveredto a target audience member by a text message. The text messageoriginated by an audience member can be input by voice, keyboard typing(using a physical keyboard or a virtual keyboard), handwriting (using aphysical pad or a virtual pad). The text message delivered to the targetaudience member can be displayed within the VR scene as a pop-up objectthat can be viewable selectively by the target audience member (in someimplementations, not viewable by non-target audience members). Dependingupon implementation-specific or other considerations, the voice and/ortext message can be communicated between two audience members and amongthree or more audience members. That is, a message in a communicationcan be delivered to multiple audience members. For example, an attorneywho is being immersed in a VR scene of a crime scene that is beingplayed in a courtroom can send a confidential text message to a client(e.g., defendant), who is also being immersed in the VR scene.

In a specific implementation, an audience member who is immersed in a VRscene using a VR playback device can have a gesture message delivered toa target audience member immersed in the VR scene, by having an avatarof the originating audience member that appears in the VR scene toperform a gesture. In a specific implementation, the multiusernavigation engine 520 maintains logs of communication among audiencemembers, in a searchable format, so the logs can be retrieved later. Ina specific implementation, the multiuser navigation engine 520 furtherenables multiple audience members to exchange (swap) FOVs with eachother (without changing respective audience member position andorientation).

The VR scene guiding engine 522 of the VR scene rendering subsystem 516enables one audience member (a guide) to guide one or more otheraudience members (followers) in the VR scene. In a specificimplementation, the VR scene guiding engine 522, similarly to themultiuser navigation engine 520, enables multiple audience members to beimmersed in the same VR scene; however, differently from the multiusernavigation engine 520, forces followers to follow a guide'sinstructions, FOV, or activity. For example, a guide may requirefollowers to move with the guide. In a specific implementation, therelative positions among followers are preserved when moved by theguide, but FOVs are repositioned as appropriate for the new grouplocation. Depending upon implementation-specific or otherconsiderations, a follower may move in the VR scene when not slaved to aguide. For example, when the guide invokes a teleport for a group offollowers, any teleporting action invoked by a follower is preemptivelysuspended until the group gets teleported according to the teleportationinvoked by the guide. A teleporting action invoked by followers may beallowed by the guide after the group teleportation is complete.

Depending upon implementation-specific or other considerations, the VRscene guiding engine 522, operating in conjunction with the multiusernavigation engine 520, enables followers to exit and reenter a guidedtour provided by a guide. For example, when a follower does not feellike looking at a FOV of a guide (e.g., a gruesome object), the followermay change FOV from that of the guide to a preferred FOV different fromthe FOV of the guide. Thus, while the guide can control a default FOV(e.g., what is in front of a follower), it may be desirable to allowfollowers to look away. In a specific implementation, the guide may alsoforce an object into follower FOVs such that the object moves withchanges in FOV (e.g., an instruction to remove a

VR headset could be displayed in the center of a FOV no matter where afollower looks).

The VR scene guiding engine 522 of the VR scene rendering subsystem 516enables communication among audience members in a similar manner as themultiuser navigation engine 520.

The VR scene observing engine 524 of the VR scene rendering subsystem516 enables an authorized audience member (an observer) to navigate theVR scene while invisible to another audience member. In a specificimplementation, no avatar of an observer appears in a VR scene, suchthat other audience members who are immersed in the VR scene cannot seethe observer. In a specific implementation, the VR scene observingengine 524 supports functions supported by the VR scene navigationengine for audience members, such as step-by-step walking, media review,teleportation, dollhouse teleportation, directed move, and/orverbal/gesture command. It may be noted the navigation techniques ofobservers and other audience members need not be the same. That is,observers are capable of operating those functions independently fromother audience members. Depending upon implementation-specific or otherconsiderations, the VR scene observing engine 524 may or may not supportcommunication functions between multiple observers and/or between anobserver and an audience member who is not an observer.

In the example of FIG. 5, the object manipulation engine 526 is intendedto represent specifically-purposed hardware and software that enablesmanipulation of objects within a scene. In a specific implementation,the object manipulation engine 526 provides haptic feedback when anaudience member reaches out to an object in a VR scene and a body part(e.g. hand) collides with the object, and enables the audience member to“grab” the object and move the object (e.g., raising the object andplacing the object close to the audience member's “eyes”) to inspect theobject. In a specific implementation, the object manipulable by audiencemembers in the VR scene may be a copy (replica) of the object. That is,even when an audience member grabs an object, the object may still existat the original position from the perspective of other audience members,and the original scene model can be preserved regardless of manipulationof objects in the VR scene. This functionality also enables multipleaudience members to independently manipulate the same objectconcurrently. In contrast, in a specific implementation, the objectmanipulation engine 526 may enable authorized audience members to modifythe scene model by adding, updating, moving, or removing objects in theVR scene. For example, an authorized user may turn on a TV in a VR sceneor move a TV from the living room to the kitchen. The objects in the VRscene may include objects scanned or captured from a real world(hereinafter referred to as scanned objects), synthetically-createdobjects that are not the scanned objects (hereinafter referred to assynthetic objects), or hybrid objects that include both scanned andsynthetic components. Scanned, synthetic, and hybrid objects are, atleast conceptually, all part of the element datastore 506.

In a specific implementation, an agent uses the object manipulationengine 526 to retrieve an object from the element datastore 506 andplaces the object in a VR scene at a position designated by the agent.In a particular example, a synthetic object may include a virtual DNAswab or a virtual gun that was not found in the real world site.Depending upon implementation-specific or other considerations,placement of a synthetic object can create a hypothetical VR scene thatcould have been. In an example, the object manipulation engine 526enables an agent to place an object in the VR scene at a particularpoint in time and a particular position, and make the placed object movein a particular manner during a particular period of time, as asimulation of an object. In another example, the object manipulationengine 526 enables an agent to place a particular person in the VR sceneat a particular point in time and a particular position, and make theplaced person act in a particular manner during a particular period oftime, as an impersonation. In a specific implementation, data of theplaced object and/or the placed person are stored in datastore andmanaged as a media file, and a representation (e.g., icon) of the mediafile is presented in the VR scene. The media file of the simulatedobject and/or the impersonation can be played, paused, forwarded,reversed, speeded up, and speeded down, in a similar manner as othermedia files, by operating the representation of the media file.

In a specific implementation, the synthetic object may be a measuringitem (e.g., a measuring tape) to measure objects (e.g., scanned objects)in the VR scene. In a more particular example, the synthetic object maybe a laser pointer having a tube shape, such that the laser pointer canbe put in a bullet hole existing in the VR scene and a trajectory of abullet can be identified based on the laser. In another specificimplementation, the synthetic object may be any item that an audiencemember uses to demonstrate how to perform a task with the item in the VRscene. For example, in a situation where a guide and one or morefollowers are in the VR scene, the object manipulation engine 526operates in conjunction with the VR scene guiding engine 522, such thatthe guide can demonstrate how to investigate the VR scene using a deviceof the synthetic object, and a follower can observe how the task isperformed using the device. Similarly, an observer may be capable ofplacing objects as desired to assist in a learning task.

In a specific implementation, the object manipulation engine 526 enablesan audience member to replace a scanned object with a hybrid object orprovide a synthetic object to represent a (predicted) real world objectthat has not been sensed. The synthetic object may be a predicted objectthat would have been at a certain previous point in time before the timeof the real world site, or an object having features described based onuser inputs or statements. In a particular example situation, thisfunctionality of the object manipulation engine 526 helps to distinguisha scanned object with a hypothetical object described based on witnesstestimony.

In a specific implementation, the object manipulation engine 526operates in conjunction with the multiuser navigation engine 520 or theVR scene guiding engine 522, to enable an audience member to place anobject (e.g., a synthetic object) within the audience member's FOV andmirror the audience member's FOV to other audience members' FOVs. Forexample, when a guide moves a synthetic object (e.g., a document) withinthe guide's FOV, the guide's FOV including the synthetic object can be“mirrored” to follower FOVs. That is, the same FOV is presented to thefollowers.

In a specific implementation, the object manipulation engine 526operates in conjunction with the multiuser navigation engine 520 or theVR scene guiding engine 522, to enable a user to place an object withinthe user's FOV and present a relative FOV to other users. For example,when a guide user moves a synthetic object (e.g., a kinfe) within theguide user's FOV, the manipulation action of the guide user is reflectedto FOV of each of follower users, i.e., a different FOV is presented toeach of the follower users, depending on the relative position of thefollower users in the VR scene.

In a specific implementation, the object manipulation engine 526operates in conjunction with the multiuser navigation engine 520 or theVR scene guiding engine 522, to enable multiple audience members tomanipulate a single object cooperatively. For example, two guides (ortwo synthetic object “coroners”) can lift up an object (e.g., a deadbody) to demonstrate to followers how coroners lift bodies.

In the example of FIG. 5, the VR scene annotation engine 528 is intendedto represent specifically-purposed hardware and software that enablesaudience members to add annotations to VR scenes obtained from the scenedatastore 508. In a specific implementation, the VR scene annotationengine 528 enables an audience member to create free-style marks byusing hand gestures using tools, such as 3D pencils, 3D highlighters, 3Dpost-its, etc. In another specific implementation, the VR sceneannotation engine 528 enables an audience member to select one ofdefault or previously-created marks by using an audience member's handmenu user interface (UI), with which the audience member can toggle andselect a mark from a list of marks. In still another specificimplementation, the VR scene annotation engine 528 enables an audiencemember to modify or edit (e.g., reposition, remove) default orpreviously-created marks that have been attached to a VR scene by usingan audience member's hand menu user interface (UI), with which theaudience member can modify or edit the mark. In still another specificimplementation, the VR scene annotation engine 428 operates inconjunction with the multiuser navigation engine 520 or the VR sceneguiding engine, such a marker can be instantly viewable by otheraudience members in the VR scene. This functionality is useful when oneaudience member is joining the VR scene from a remote location differentfrom a real world place corresponding to the VR scene, and instructsanother audience member who is also joining the VR scene (AR scene) atthe real world place.

In a specific implementation, the VR scene annotation engine 528 enablesan audience member to attach a media file (audio, video, documents, 3Dscan data) and any other representation relevant information to a VRscene and place a representation (e.g., icon) of the media file withinthe VR scene. For example, an audience member can select a media file tobe attached to a VR scene from a library and select an object to whichthe media file is to be attached. Upon selection of the media file andthe object, a representation of the media file is presented in the VRscene in association with the selected object (e.g., at a positionadjacent to the object). In a specific example, the media file is aclose-up picture of an object (e.g., a bullet hole), or a reportdocument (e.g., ballistics report) of the object (e.g., a bullet hole).In another specific example, the media file is a photographic imagecaptured at a location remote from a real world location for which theVR scene is created (e.g., an image of a police investigation boardshowing relevant information of a case).

In a specific implementation, the VR scene annotation engine 528 enablesan audience member to attach a voice memo to a VR scene and place arepresentation (e.g., icon) of the voice memo within the VR scene. In anexample, an audience member can select an object in a VR scene or anobject synthetically created as a target object with which the voicememo is to be associated, and record the audience member's voice througha microphone of a VR playing device that the user is using. In anotherexample, a user can record the audience member's voice and then selectan object with which the recorded voice is to be associated. Arepresentation (e.g., icon) of the voice memo is presented in the VRscene at a location associated with the object, and the audience memberwho made the voice memo or any other audience members who are authorizedto access the voice memo can play back the voice memo by selecting therepresentation. In still another example, a voice memo may be generallyassociated with a VR scene, and may not be associated with a specificobject within the VR scene.

In a specific implementation, the VR scene annotation engine 528 enablesan audience member to attach a text memo to a VR scene and place arepresentation (e.g., icon) of the text memo within the VR scene. In anexample, an audience member can select an object in a VR scene or anobject synthetically created as a target object with which the voicememo is to be associated, and recognize the audience member's text inputthrough a physical or virtual keyboard. In another example, an audiencemember can input a text memo and then select an object with which thetext memo is to be associated. A representation (e.g., icon) of the textmemo is presented in the VR scene at a location associated with theobject, and the audience member who made the text memo or any otheraudience members who are authorized to access the text memo can open andreview the text memo by selecting the representation. In still anotherexample, the VR scene annotation engine 528 operates to dictate anaudience member's verbal input into a text memo, and the text memo canbe attached to a VR scene. In still another example, a text memo may begenerally associated with a VR scene, and may not be associated with aspecific object within the VR scene.

In a specific implementation, the VR scene annotation engine 528,operating in conjunction with the object manipulation engine 526, andwith the VR scene guiding engine 522, generates a script based on anactivity of an audience member (e.g., a guide or observer) performed onan object in the VR scene. For example, when a guide shows demonstrationof how to handle an object in the VR scene (e.g., collecting bloodsample), the VR scene annotation engine 528 enables a follower to createa script of an activity to be performed thereby based on the guide'sactivity. The follower can refer to the script when the follower isrequested to perform the same activity as the guide user did. Thisfunctionality of generating a script benefits trainees of a trainingprogram to efficiently create a script based on the activity of theguide (e.g., trainer).

In a specific implementation, the VR scene annotation engine 528,operating in conjunction with the object manipulation engine 526, andwith the VR scene observing engine 524, generates a script based on anactivity of a user performed on an object with the VR scene, withoutbeing noticed by the user. For example, when a user, e.g., a trainee ofa training program, performs a task required to take, the VR sceneannotation engine 528 enables an observing user (e.g., trainer) tocreate a script of an activity that has been performed by the user beingobserved. The observing user can refer to the script when the observinguser evaluates performance of the user being observed. In a specificimplementation, the VR scene annotation engine 528 compares thegenerated script with a reference script corresponding to an exemplaractivity to be performed, and generates evaluation result (e.g., grade)based on the comparison. More specifically, the VR scene annotationengine 528 compares each step of activity performed by the user beingobserved and an order of the steps of the performed activity with eachstep of an exemplar activity and an exemplar order, respectively. Thisfunctionality of generating a script benefits an observing user (e.g., atrainer of a training program) to efficiently create a script and/ormake an evaluation result based on the activity of the user beingobserved (e.g., trainer).

In the example of FIG. 5, the summary generation engine 530 is intendedto represent specifically-purposed hardware and software that creates asummary report for a session of being immersed into a VR scene by one ormore users and/or a summary report for each user and/or each objectinvolved in the session. In this paper, a session is intended to be aperiod time during which one or more users are immersed in a VR scene,i.e., a period of time between a first login to the VR scene to a lastlogout of the VR scene. In a specific implementation, the summarygeneration engine 530 is configured to create a summary report thatsummarizes a session of a VR scene in which one or more usersparticipate to be immersed. The summary report, for example, includeseach user's movement in the VR scene, which is generated by the summarygeneration engine 530 operating in conjunction with the VR scenerendering subsystem 516. The summary report, for example, includes eachobject's movement in the VR scene which is generated by the summarygeneration engine 530 operating in conjunction with the objectmanipulation engine 526. The summary report, for example, includes eachannotation attached to the VR scene and/or summary of the attachedannotations, which are generated by the summary generation engine 530operating in conjunction with the VR scene annotation engine 528. Thesummary report, for example, includes a guided tour video clip that canbe seen by a follower user of a group guided by a guide user, and aguide route in the VR scene. The summary reported is created in any dataformat, and may be a text format for example. In an example situation,this functionality of creating a summary report helps law enforcementagents to efficiently prepare a more coherent report aimed at targetaudience (e.g., jury) of the report.

In a specific implementation, the summary generation engine 530 isconfigured to create a summary report that summarizes one user'sactivity in the VR scene. The summary report, for example, includes auser's movement in the VR scene, which is generated by the summarygeneration engine 530 operating in conjunction with the VR scenerendering subsystem 516. The summary report, for example, includes eachobject's movement manipulated by the user in the VR scene, which isgenerated by the summary generation engine 530 operating in conjunctionwith the object manipulation engine 526. The summary report, forexample, includes each annotation attached to the VR scene by the userand/or summary of the attached annotations, which are generated by thesummary generation engine 530 operating in conjunction with the VR sceneannotation engine 528. The summary report, for example, includes asequence of FOVs presented to the user. The summary reported is createdin any data format, and may be a text format for example.

In an example of operation, a system such as is illustrated in FIG. 5operates as follows. The scene datastore 508 stores data of VR scenesthat have been created. A user authorization engine carries out userauthentication when a user attempts to access a VR scene stored in thescene datastore 508, the VR scene rendering subsystem 516 presents VRscenes obtained from the scene datastore 508 to VR playback devicesassociated with authorized users, the object manipulation engine 526enables a VR object in a VR scene to be manipulable by users in the VRscene, the VR scene annotation engine 528 enables user to add annotationto VR scenes obtained from the scene datastore 508, and the summarygeneration engine 530 is configured to create a summary report thatsummarizes a session of a VR scene in which one or more audience membersparticipate to be immersed. For example, the VR authorization enginedetermines presentation modes, such as a sole navigation mode, amultiple navigation mode, a guiding mode, and an observing mode, thatcan be selected by an audience member, determines objects that can bemanipulated by the audience member and media that can be played orreproduced by the audience member, and annotation (text, voice, media,etc.) that can be put by an audience member.

In the VR scene rendering subsystem 516 illustrated in FIG. 5, the VRscene navigation engine 518 enables each of authorized users who areaccessing the VR scene to navigate the VR scene, the multiusernavigation engine 520 enables multiple users to interact to each otherin the VR scene, the VR scene guiding engine 522 enables one user toguide one or more other users in the VR scene, and the VR sceneobserving engine 524 enables authorized users who are accessing the VRscene to navigate the VR scene while visible to other users.

FIG. 6 depicts a flowchart 600 of an example of a method for VR scenepresentation and interaction. The flowchart 600 starts at module 602with presenting a VR scene based on a scene model obtained from thescene datastore 508 to VR playback devices associated with authorizedusers. A user is able to navigate through a VR scene by moving aroundthe VR, communicate with other users in the VR scene, and force otherusers to move along with a guide user when a guide tour of a group ofusers is established activating a guide mode. Depending uponimplementation or other considerations, a user is able to be transparent(not viewable from other users), when an observation mode is activated.

In the example of FIG. 6, the flowchart 600 continues to module 604 withenabling objects in a VR scene to be manipulable by users in the VRscene. In a specific implementation, a user is able to move an objectincluded in the VR scene as desired by a user, add a synthetic object tothe VR scene, remove an object from the VR scene, sort out objects inthe VR scene based on a particular criteria. In a specificimplementation, a user is able to present an object manipulated by theuser to other users in a VR scene.

In the example of FIG. 6, the flowchart 600 continues to module 606 withenabling users to add annotations to VR scenes. In a specificimplementation, a user is able to attach a mark, a media file, a textmemo, an audio or a video memo to a VR scene or any specific objectwithin the VR scene. In a specific implementation, a user is able toshow a representation (e.g., icon) to review or play the attachedannotation within a VR scene, for example, at a location adjacent to anassociated object, if any.

In the example of FIG. 6, the flowchart 600 ends at module 608 withcreating a summary report for a session of being immersed into a VRscene by one or more users and/or a summary report for each user and/oreach object involved in the session. In a specific implementation, thesummary report may include a user's movement in the VR scene, eachobject's movement manipulated by the user in the VR scene, eachannotation attached to the VR scene by the user and/or summary of theattached annotations, and/or a sequence of FOVs presented to the user.In a specific implementation, when a summary report is created for anentire session of a VR scene in which a plurality of user logs in atdifferent timings, user activity since a first user logs in the VR sceneuntil a last user logs out of the VR scene is monitored, and the summaryreport is created upon the last user logging out of the VR scene. In aspecific implementation, when a summary report is created for eachindividual user, user activity since the user logs in the VR scene untilthe user logs out of the VR scene is monitored, and the summary reportis created upon the user logging out of the VR scene.

FIG. 7 depicts a diagram 700 of an example of a scene filtering system702. The scene filtering system 702 includes a scene datastore 704, auser filtering engine 706, an object filtering engine 708, and a mediafiltering engine 710.

In the example of FIG. 7, the scene datastore 704 can be implemented asdescribed with reference to the scene datastore 108 (FIG. 1) and/or thescene datastore 508 (FIG. 5).

In the example of FIG. 7, the user filtering engine 706 is intended torepresent specifically-purposed hardware and software that filters userswho are authorized to access a VR scene. In a specific implementation,the user filtering engine 706 assigns a user identifier (e.g., user ID)to each user who has an account to a VR experience system in associationwith a unique user access level identifier (e.g., level 1, level 2,level 3, . . . ) to categorize user access levels of users, and enablesaccess to a VR scene based on the user identifier and/or assigned useraccess level identifiers. For example, the user filtering engine 706disables access to a VR scene by a specific user who has made anunethical conduct in a scene during a VR scene (e.g., an educational VRscene), based on a user identifier of the user. In another example, theuser filtering engine 706 enables access to a VR scene by users having auser access level identifier higher than (or equal to) a predeterminedthreshold (e.g., level 2), and disable access to the VR scene by usershaving a user access level identifier lower than (or equal to) thepredetermined threshold. In a specific example, the user filteringengine 706 assigns a lower access level to certain users (e.g., jury),and a higher access level to other users (e.g., judges and attorneys),to prevent a graphic scene or a VR scene that has too strong influenceon an outcome of a case to be observed by jury. In other words, the userfiltering engine 706 is able to deny access to a VR scene that isinadmissible as evidence.

In the example of FIG. 7, the object filtering engine 708 is intended torepresent specifically-purposed hardware and software that filtersobjects to be viewable by users in a VR scene from the VR scene. In aspecific implementation, the object filtering engine 708 assigns anobject identifier (e.g., object ID) to each object in a VR scene inassociation with a unique object access level identifier (e.g., level 1,level 2, level 3, . . . ) to categorize user access levels of objects,and enables observation of objects in to a VR scene based on the objectidentifier and/or the assigned object access level identifiers. Forexample, the object filtering engine 708 disables observation (viewing)of an object having an object identifier by all users in a VR scene. Inanother example, the object filtering engine 708 enables observation(viewing) of objects having an object access level identifier higherthan (or equal to) a predetermined threshold (e.g., level 2), anddisable observation (viewing) of other objects having an object accesslevel identifier lower than (or equal to) the predetermined threshold.In still another example, the object filtering engine 708, inconjunction with the user filtering engine 706, enables users having auser access level identifier higher than (or equal to) a predeterminedthreshold (level 3) to view objects having an object access levelidentifier higher than (or equal to) a predetermined threshold (level5), and disables users having a user access level identifier lower thana predetermined threshold (level 2) to view objects having an objectaccess level identifier lower than a predetermined threshold (level 5).In a more specific example, the object filtering engine 708 enablesobservation of objects (e.g., objects inadmissible as evidence) by users(e.g., judges and attorneys) and disables observation of the objects byother users (e.g., jury).

In the example of FIG. 7, the media filtering engine 710 is intended tospecifically-purposed hardware and software that filters media files tobe accessible by users in a VR scene from the VR scene, in a similarmanner as filtering of objects by the object filtering engine 708. Thatis, the media filtering engine 710 assigns a media file identifier and aunique media access level identifier to each media file in a VR scene,and restricts access to a media file based on a media file identifierand/or media access level identifier of the media file. In addition, themedia filtering engine 710 operates, in conjunction with the userfiltering engine 706 to allow access to a media file to limited users,and/or operates, further in conjunction with the object filtering engine708, to allow access to a media file to limited users having access to aparticular object or objects of particular access level(s).

FIG. 8 depicts a flowchart 800 of an example of a method for carryingout filtering of a VR scene. The flowchart 800 starts at module 802 withfiltering users who are authorized to access a VR scene based on a useridentifier and/or user access level identifier.

In the example of FIG. 8, the flowchart 800 continues to module 804 withfiltering objects in the VR scene viewable by users in a VR scene basedon an object identifier and/or object access level identifier. In aspecific implementation, the filtering of the objects in a VR scene iscarried out with respect to all users in the VR scene, or with respectto part of the users based on the user identifiers and/or user accesslevel identifiers.

In the example of FIG. 8, the flowchart 800 ends at module 806 withfiltering media files in or associated with the VR scene viewable byusers in a VR scene based on a media identifier and/or media accesslevel identifier. In a specific implementation, the filtering of themedia files in a VR scene is carried out with respect to all users inthe VR scene, or with respect to part of the users based on the useridentifiers and/or user access level identifiers. In a specificimplementation, the filtering of the media files in a VR scene iscarried out with respect to whether or not users have access to objectsin the VR scene, e.g., access to a particular object having an objectidentifier and/or access to object having a particular object accesslevel identifier(s).

These and other examples provided in this paper are intended toillustrate but not necessarily to limit the described implementation. Asused herein, the term “implementation” means an implementation thatserves to illustrate by way of example but not limitation. Thetechniques described in the preceding text and figures can be mixed andmatched as circumstances demand to produce alternative implementations.

We claim:
 1. A method comprising: obtaining real world image data usingone or more image data capturing devices positioned at a real worldsite; obtaining real world non-image data using one or more sensorspositioned at the real world site; creating a scene model based on theobtained real world image data; integrating the obtained real worldnon-image data with the created scene model; carrying out an objectrecognition process to identify one or more objects included in thescene model; rendering the scene model to create a VR scene in which oneor more users are immersed using one or more VR playback devices.
 2. Themethod of claim 1, wherein the non-image data include audio data, andintegrating the obtained real world non-image data comprises arepresentation of the audio data in the scene model, activation of therepresentation in the VR scene through one of the VR playback devicescausing playing of the audio data on the one of the VR playback devices.3. The method of claim 1, wherein the non-image data include non-audiodata, and integrating the obtained real world non-image data comprisesplacing a representation of the non-audio data in the scene model,activation of the representation in the VR scene through one of the VRplayback devices causing displaying of information corresponding to thenon-audio data on the one of the VR playback devices.
 4. The method ofclaim 1, further comprising: when a plurality of users is immersed inthe VR scene, detecting a communication input by one of the plurality ofusers through one of the VR playback devices; generating a communicationoutput to another one of the VR playback devices based on thecommunication input.
 5. The method of claim 4, wherein the communicationinput is at least one of a text input, a voice input, a gesture input,and the communication output is of a different format from a format ofthe communication input.
 6. The method of claim 1, further comprising:when a plurality of users is immersed in the VR scene, reflecting afield of view (FOV) of the VR scene presented to one of the plurality ofusers to a FOV of the VR scene presented to another one of the pluralityof users.
 7. The method of claim 1, further comprising: when a pluralityof users is immersed in the VR scene, during a first operational mode,presenting a representation of each of the plurality of users in the VRscene, so as to be mutually viewable in the VR scene; during a secondoperational mode, hiding a representation of at least one of theplurality of users in the VR scene, so as to be not viewable in the VRscene.
 8. The method of claim 1, further comprising: detecting a userinput to add a synthetic virtual object on one of the VR playbackdevices; presenting the synthetic virtual object in the VR scene.
 9. Themethod of claim 1, further comprising: detecting a user input to add anannotation on one of the VR playback devices; presenting arepresentation of the annotation in the VR scene, activation of therepresentation of the annotation in the VR scene causing displaying orplaying of the annotation.
 10. The method of claim 1, furthercomprising: tracking activity of at least one of the users in the VRscene; generating a report regarding the activity of the at least one ofthe users based the tracked activity.
 11. A system comprising: at leastone processor and memory configured to store instructions to instructthe at least one processor to: obtain real world image data using one ormore image data capturing devices positioned at a real world site;obtain real world non-image data using one or more sensors positioned atthe real world site; create a scene model based on the obtained realworld image data; integrate the obtained real world non-image data withthe created scene model; carry out an object recognition process toidentify one or more objects included in the scene model; render thescene model to create a VR scene in which one or more users are immersedusing one or more VR playback devices.
 12. The system of claim 11,wherein the non-image data include audio data, and the instructions arefurther configured to instruct the at least one processor to place arepresentation of the audio data in the scene model, activation of therepresentation in the VR scene through one of the VR playback devicescausing playing of the audio data on the one of the VR playback devices.13. The system of claim 11, wherein the non-image data include non-audiodata, and the instructions are further configured to instruct the atleast one processor to place a representation of the non-audio data inthe scene model, activation of the representation in the VR scenethrough one of the VR playback devices causing displaying of informationcorresponding to the non-audio data on the one of the VR playbackdevices.
 14. The system of claim 11, wherein when a plurality of usersis immersed in the VR scene, the instructions are further configured toinstruct the at least one processor to detect a communication input byone of the plurality of users through one of the VR playback devices,and generate a communication output to another one of the VR playbackdevices based on the communication input.
 15. The system of claim 14,wherein the communication input is at least one of a text input, a voiceinput, a gesture input, and the communication output is of a differentformat from a format of the communication input.
 16. The system of claim11, wherein when a plurality of users is immersed in the VR scene, theinstructions are further configured to instruct the at least oneprocessor to reflect a field of view (FOV) of the VR scene presented toone of the plurality of users to a FOV of the VR scene presented toanother one of the plurality of users.
 17. The system of claim 11,wherein when a plurality of users is immersed in the VR scene, theinstructions are further configured to instruct the at least oneprocessor to: present a representation of each of the plurality of usersin the VR scene, so as to be mutually viewable in the VR scene, in afirst operational mode; hide a representation of at least one of theplurality of users in the VR scene, so as to be not viewable in the VRscene, in a second operational mode.
 18. The system of claim 11, whereinthe instructions are further configured to instruct the at least oneprocessor to: detect a user input to add a synthetic virtual object onone of the VR playback devices; present the synthetic virtual object inthe VR scene.
 19. The system of claim 11, wherein the instructions arefurther configured to instruct the at least one processor to: detect auser input to add an annotation on one of the VR playback devices;present a representation of the annotation in the VR scene, activationof the representation of the annotation in the VR scene causingdisplaying or playing of the annotation.
 20. The system of claim 11,wherein the instructions are further configured to instruct the at leastone processor to: track activity of at least one of the users in the VRscene; generate a report regarding the activity of the at least one ofthe users based the tracked activity.